（English follows Chinese）

首先我們來談談程式碼氣味（Code Smell）中的第一個分類：Bloaters 臃腫怪。我查了一下，華文世界中目前尚未有普遍公認的正式翻譯名稱，我曾看過「虛胖的程式碼」或是「代碼腫脹」這樣的描述，但我認為這些都不足以貼合這個名詞背後的意境。或許是受到Refactoring Guru網站上的插圖影響，沒有足夠留心維護的程式碼像是哥吉拉一樣逐漸演化成虛胖腫脹的怪物形象根植在我的心中，所以我選擇了這樣的華文命名。

無庸置疑的，這或許是最普遍隨處可見的程式碼氣味，廣泛存在於幾乎每一個程式專案當中。Bloaters違反了Clean Code中的最高指導原則，同時也是Sandi曾經在RailsConf 2014中「All the Little Things」所提及，寫出乾淨程式碼最關鍵的秘訣：

Make Smaller Things. - Sandi Metz, 2014

當人們詢問Sandi如何能寫出更好的物件導向程式碼時，其中一個最棒的建議是：創造出更小的物件（make smaller things）。更小的類別，更小的方法，然後讓他們彼此所知越少越好。

通往「壞味道」的道路時常由「過於肥大」鋪成，畢竟肥大虛胖往往擺脫不了惡臭油膩的形象。而這樣的連結根本原因實則來自於人類大腦中對於概念的掌握有其短期上限。程式碼並非僅只是交由電腦執行，更多數的時候，需要由開發者透過肉眼閱讀後理解，這兩者同等重要，甚至我個人認為後者的重要性更遠勝於前者。回歸初始，程式碼一開始就是為了讓人類能夠更方便快速地與電腦互動的產物，否則人類直接編寫「1010」便完事，不需要特意發明各種貼近人類自然語法的程式語言來與電腦溝通意圖。

人類同時間能掌握的概念是有極限的，與現代的伺服器不同，實際上沒有人真正能夠像是「多執行緒」一般的工作，每個人只能把眼前的一件事處理好，然後進行下一件事。當概念一多，人類的大腦便需要更多資源在腦中構建虛擬空間去理解複雜的結構關係與邏輯，而這樣的思維負擔往往容易造成疏忽或是錯誤。這正是為何多數的程式語言，都會有建議的類別長度上限，甚至是每行程式碼的長度上限，就是為了能夠盡可能控制腦中同時接收資訊的數量，不要超過人類負荷的上限。

如同其他氣味，Bloaters會讓專案變得很難以維護。不只讓開發者需要耗費更多時間去閱讀，同時也會讓修改程式碼的成本增加。通常來說，專案初始階段類別與方法都還算是苗條，但隨著專案年齡逐年遞增，程式碼年復一年變得臃腫起來。尤其是當開發者只關注眼前的錯誤修復與新功能實作，卻沒有以專案整體的視角去審視優化，就很可能會忽略了這些長期的隱憂。

要改善這樣的氣味，如同普遍建議的重構技巧，期望能夠一步登天是不切實際的。如同五洲製藥的理念：先研究不傷身體（現有行為）再講求效果。重構很重要的就是不能破壞現有行為，創造出更多錯誤與風險。把重構的步驟與改變切小，有助於逐步管控變化與風險，更能夠讓團隊與主管接受重構的行為。對於提交出的程式碼改動，小的Pull Requests也能更好的被檢視。

幸運的是，這系列文章正是想要仔細討論氣味與重構之間的對應關係。我相信當開發者能夠辨識出氣味的同時，就可以根據這些前人的經驗，快速得到重構的技巧與指引，不需要重新造輪，而是穩穩站在技術社群的最佳實踐上，將創造力發揮在更有價值之處。

接下來讓我將介紹Bloaters分類下的五種氣味：

Long Method 長方法

基本上，任何方法超過五行都可能太長了。

Large Class 大類別

一個類別內擁有太多的方法、屬性、以及太長的程式碼。

Primitive Obsession 基本型別偏執癖

過度依賴程式語言所提供的基本型別（如String、Interger、Array等）。

Long Parameter List 長參數

參數太長了！

Data Clumps 資料團塊

相關的資料總是同時出現在程式碼周遭，拿掉其中一部分會失去商業邏輯上的意義。

關於每一種氣味以及對應的重構方法，超連結會在日後文章完成時補上，敬請期待。一樣感謝各界好友的閱讀與支持，美好的假日由咖啡與寫作開始，似乎也是不錯的選擇（自我催眠）。

The first category of code smells we will discuss is called Bloaters. It is one of the most common signs of code smells that can be found in any code branch. Bloaters exactly go against the top secret of Clean Code, mentioned in Sandi Metz's other talk "All the Little Things" at RailsConf 2014.

Make Smaller Things. - Sandi Metz, 2014

When people ask Sandi what the best way to write better object-oriented code is, one of the best pieces of advice is to make smaller things. Make smaller classes, make smaller methods, and let them know as little about each other as possible.

Size can be evil, and this limitation comes from the human brain. Code is not only meant for computers to execute but also for developers to read. The amount of information and concepts humans can process at once is strictly limited. Unlike servers that can run multiple threads, developers cannot do the same mentally. That's why it is recommended to follow guidelines for the length of each file and line of code.

Bloaters make software difficult to work with. They represent pieces of code that have grown so large that they become hard to read and maintain.

Typically, bloaters don’t happen right away but accumulate long-term as your code base grows. This is usually a slow process. Code starts out small and well-isolated, but grows excessively over a long time as new functionality is added and code is made more general marking it difficult to work with. Particularly when no developer has made an effort to point out the potential issue.

Dealing with these code smells, like most refactoring, is usually best done one small step at a time.

The good news is that if you can identify any of the smells below in your components you can make your code cleaner with the same kind of gradual changes that caused the problems in the first place.

Let's take a look at some common code smells in the Bloaters catalog:

Long Method

Generally, any method longer than ten lines are considered too long. It may be responsible for more tasks than it should be.

Large Class

A class contains too many fields, methods, and lines of code.

Primitive Obsession

Primitive Obsession is the excessive use of basic data types to represent concepts or entities in code.

Long Parameter List

When a function or method has a large number of parameters.

Data Clumps

Groups of variables that always appear together should be turned into their own object.

Reference

All the Little Things, Sandi Metz https://youtu.be/8bZh5LMaSmE

https://medium.com/@joshsaintjacque/reacting-to-code-smells-bloaters-3e452d0c01b

https://medium.com/testvagrant/refactoring-101-code-smells-bloaters-f80984859340

https://bytelanguage.com/2018/02/19/code-smells-bloaters-long-methods-long-class/

https://www.jobsity.com/blog/how-to-identify-code-smells

https://code-smells.com/

Chinese reference

http://gelis-dotnet.blogspot.com/2023/02/code-smell-or-bad-smell.html
https://blog.csdn.net/weixin_41937380/article/details/127603069